home *** CD-ROM | disk | FTP | other *** search
/ United Public Domain Gold 2 / United Public Domain Gold 2.iso / music_utilities / pt030.dms / pt030.adf / Scheme / plans.doc < prev    next >
Text File  |  1987-06-15  |  3KB  |  85 lines
  1. ===========================
  2. FUTURE PLANS FOR THE SYSTEM
  3. ===========================
  4.  
  5. Scheme
  6. Version 1.2
  7. 19-March-1988
  8.  
  9.  
  10. TOPICS
  11. ------
  12. NUMBERS
  13. DUMP-OBJ
  14. COMPILER
  15. INTERFACES
  16.  
  17.  
  18.  
  19. ================================================================================
  20.  
  21. NUMBERS
  22. -------
  23. I hope to extend the number system soon.  Bignums and rational numbers are
  24. high priority on my list.  However, floating point numbers will eventually
  25. be needed; they are probably the best way to implement transcendental
  26. functions.
  27.  
  28. The hardest part (or at least the part I'm the least enthused about) is the
  29. number <-> string conversion functions.  These will be tough.
  30.  
  31.  
  32.  
  33. ================================================================================
  34.  
  35. DUMP-OBJ
  36. --------
  37. Something I'm quite excited about implementing is a dump-obj function. This
  38. would dump some representation of a Scheme object and all of its associated
  39. objects to a file.  Later, this file could be loaded back into the system.
  40.  
  41. To save the entire system, you would just do (dump-obj (the-environment))
  42. from the top-level.  This would allow you to save your own customized
  43. versions of Scheme, without loading in a lot of initialization each time.
  44.  
  45. The process would be a lot like a garbage collection, except that addresses
  46. would have to be marked in a relocation table, and things like symbols'
  47. names would have to be noted as well.  There are also some sticky issues,
  48. like what does one do with open ports?
  49.  
  50.  
  51.  
  52. ================================================================================
  53.  
  54. COMPILER
  55. --------
  56. There are provisions for compiled functions in the interpreter.  In fact, I
  57. have code (sans code generators) for a couple of compilers now. Some issues
  58. are:
  59.  
  60.     * How should relocation be handled so that compiled code will interact
  61.       well with things like dump-obj and the garbage collector?
  62.  
  63.     * Should the compiler produce an intermediate file such as would be
  64.       produced by dump-obj?
  65.  
  66.  
  67.  
  68. ================================================================================
  69.  
  70. INTERFACES
  71. ----------
  72. It would be nice to provide external library interfaces through functions
  73. packaged in their own environments.  For example, you could load the
  74. AmigaDOS environment and then access functions out of that environment.
  75.  
  76. There are some problems, though.  I don't think it would be a great idea
  77. to start adding a bunch of new object types into the system; it makes
  78. garbage colletion and dump-obj? harder than ever.
  79.  
  80. Another possibility is to provide interface through AmigaDOS handlers.    Then
  81. system interfaces could be gained through the existing filesystem interface.
  82. (How about a GFX: handler?)  But, there are probably some things that
  83. just wouldn't work well as handlers.
  84.  
  85.